The current SQL standard for access control is coarse grained, in that it grants access to all rows of a table or none. Fine-grained access control, which allows control of access at the granularity of individual rows, is required in practically all database applications, for example, to ensure that employees can see only their own data, and relevant data of other employees that they manage. While fine-grained access control has traditionally been performed at the level of application programs, there is an increasing need to support it at the database level. However, implementing security at the application level makes management of authorization quite difficult. In addition to presenting a large surface area for attackers, any breach of security at the application level exposes the entire database to damage, since every part of the application has complete access to the data belonging to every application user.
There are several models for fine-grained access control. In a class of models, called Truman models, one conventional architecture provides access control through functions that return strings containing predicates. A function is associated with each relation, and when invoked, returns a string containing predicates that enforce fine-grained access control; the function takes as input the mode of access and an application context which includes information such as user-id of the end user. In another conventional system, policy-based security management allows specification of predicates that are added to WHERE clauses. Different policies can be specified on different columns and are automatically combined.
Cell-level access control is another conventional fine-grained access methodology; however, this technique is restricted to handling privacy policies, and does not constitute a general-purpose access control mechanism. Others include using predicated grants to manage cell-level access control and adding predicates to SQL (structured query language) authorization grants.
A non-Truman model can be attractive for several reasons, such as guaranteeing correctness. That is, if a query is accepted, it will give the same result as if the user had full authorizations on all relations. In contrast, in the class of Truman models, the result of a query can be changed by the authorization mechanism. However, any non-Truman model implementation is likely to be unpredictable in the following sense: the model requires a powerful query inferencing mechanism and since inferencing can never be complete, a query that is accepted by one database implementation may be rejected by another (perhaps even a different version of the same database system). Such unpredictability is highly undesirable for applications, which explains why the class of Truman models is used in practice.
The most commonly used models follow a view replacement strategy that replaces relations in a user query by a view of the relation that is available to that user. Application programs often use views as a way of providing restricted access to certain users. However, there are two significant problems with most implementations of the view replacement model: performance (e.g., the overhead of the access control predicates when they are actually redundant) and security (e.g., the potential of information leakage though other channels such as user-defined function (UDF) predicates and exceptions).
With respect to performance, the original query usually includes predicates/joins that restrict access to only authorized data. The authorization checks performed in the replacement views are redundant, including not only cheap comparisons, but also expensive semi-joins. The introduction of complex authorizations also significantly increases the complexity of the query, resulting in increased optimization time, in addition to worsened execution time. In the realm of security, several attacks have been discovered against the view-based approach to fine-grained access control, based on information leakage. Although the set of results of a user query are usually not affected by these attacks, these attacks are able to leak unauthorized information through channels, such as the leakage of information through UDFs, and the leakage of information through exceptions and error messages.
For example, consider a relational schema                employee(emp_id, name, dept_id, salary),and a view        
CREATE VIEW myemployees ASSELECT * FROM employeeWHERE dept_id in Q1which authorizes the user to see only the employee tuples with dept_id in the result of query Q1. Suppose now that the user issues a query
SELECT * FROM myemployeesWHERE myudf(salary)
The query processor replaces the view myemployees by its definition. Suppose now that the query plan chosen by the optimizer executes the UDF myudf ( ) before the subquery Q1. As a result, the UDF is called on every salary value, including those of unauthorized tuples. The code defining myudf ( ) is not under the control of the authorization system, and can print out (or save in a separate relation) the salary values it has passed, thereby leaking unauthorized salary information.